In a data processing system, a backup subsystem is typically used to save a recent copy or version of one or more data sets, or a portion thereof, on some form of backup data storage device, such as magnetic or optical disk drives, tape drives, or other memory. The backup subsystem is used to protect against loss of data, should the primary data source become unreliable. For example, if a primary storage location of one or more data sets is destroyed, corrupted, deleted, or changed because of power failure, hardware, or software error, user error or some other type of problem, the latest version of those data sets which are stored in a backup subsystem can be used to restore the underlying data, thus limiting the risk of data loss. Risk of loss is minimized with frequent updates of source to backup (to the extent the source data changes). However, certain changes to the source will eventually require additional capacity in, and reconfiguration of, the backup subsystem. This reconfiguration must also consider that portions of previous primary and backup resources are no longer necessary for the current data set, and should be released for other use.
As but one example, a log-structured array subsystem (LSA) implements “virtual volumes”, wherein each virtual volume is created using a “virtual track table” having pointers to “virtual tracks” (i.e., records) in a sequential byte stream. Updated tracks are written to a new location at the logical end of the byte stream, and their associated pointers are reset to the new locations. Thereafter, the tracks at the old location in the sequential byte stream are no longer needed and can be released as free space for reclamation and reuse. The storage can take place in standard direct access storage device (DASD) with sequentially numbered tracks buy the use of an emulation system.
A problem exists in current storage systems that provide the capability to provide a backup copy of data within the storage system. The problem is related to the fact that the system does not select the target storage volume for the copy, but instead requires that the user manually select the target volume. Existing data management software for copy services technologies (e.g., FlashCopy, PPRC, XRC) typically require the user to explicitly select the underlying copy technology to be used. This is primarily due to the fact that each copy type uses different semantics and may be initialized by a different user command. For example, XRC is initialized with commands that begin with X (e.g., XSTART, XADDPAIR, XSUSPEND) whereas PPRC is managed using different commands (e.g., CESTPATH, CESTPAIR). Furthermore, even within a major copy type, certain controlling parameters must be explicitly managed, such as the ERRORLEVEL attribute for XRC and the CRIT attribute for PPRC.
As may be appreciated, this manual selection of volumes, copy type, commands, and parameters can be an error-prone procedure. In addition to manually induced copy type errors, the user may inadvertently select volumes that are in use by other systems, resulting in a possible loss of data. Furthermore, unless the user has an appreciation and knowledge of the internal architecture of the data storage system, the user will not normally select a target volume that is optimal with respect to performance, availability and/or reliability. As but one example, if the user should manually select as a target volume one having one or more tracks located on the same physical disk as the source data, then a disk failure could result in a loss of both the source volume and the target volume. The problem of manual selection of the target volume for a backup copy operation is compounded for those systems having large, virtualized data storage facilities (e.g., tens to thousands of potential target volumes located on hundreds or thousands of physical disks), as well as in those systems that provide heterogeneous and dynamic environments.
Different approaches in the prior art teach automating certain portions or certain aspects of data copying. However, none appear to incorporate all of the advantages of the present invention. For example, U.S. Pat. No. 5,809,511, entitled “Outboard Data Migration in a Volume Stacking Library”, teaches migrating data from a source media to a target media. Identifiers associated with the data are obtained from the source data and consolidated in data/identifier pairs in substantially continuous form in the target media. A catalog is created or updated to map the data blocks.
U.S. Pat. No. 5,440,735, entitled “Simplified Relational Data Base Snapshot Copying”, describes a relational database management system that permits users to specify copy operations without necessarily specifying details of structure, copy refresh algorithm, and the like. When a user initially defines or registers, for example, a source table, the user specifies a set of predefined attributes. When a user later requests a snapshot copy, the system automatically determines the nature of the copy operation to be performed by matching, for example, the table name with its registered attributes. The system is then able to automatically determine details such as structure of the table, simplifying the specification of copies in a relational database.
U.S. Patent Publication No. US 2002/0083099 A1, entitled “Document/Message Management”, concerns automatically transferring data between electronic data interchange (EDI) formats via a computer. Data is transferred from metadata elements of the source data model to variables of a virtual document, based on a mapping that has been previously made. Data assigned to the variables of the virtual document are then transferred to variables of a target data model.
U.S. Patent Publication No. US 2003/0009747 A1, entitled “Apparatus and Method for Porting Applications to Different Platforms”, describes using a mapping table function that receives source filenames (preferably flexible UNIX-type filenames) and directory structures and maps them to filenames (preferably more restrictive OS/400-type filenames) and directory structures for a target platform.
U.S. Patent Publication No. US 2002/0174098 A1, entitled “Method and System for Providing a Dynamic and Real-Time Exchange Between Heterogeneous Database Systems”, explains a system for dynamically exchanging databases in real-time. A database table migration means is used for executing data migration by selecting a source database and a destination database, and then selecting a source data table as a basis for selecting a migration mode. A data mapping rule is used for mapping a data field via multiple operations and for automatically encoding and interpreting after selecting the source.
The above prior art approaches provide automation of certain aspects of data copying, but either require extensive database searches of every available target volume to find a suitable one, or ignore non-technical aspects of configuring a resource (e.g., a target volume) that would optimize the resource for a user's particular needs, needs that may be related to more than just technical compatibility of resources.
While the above background description relates to data storage, such is deemed merely one application of the principles of the present invention, which may be used to self-configure a compatible resource in any field by matching desired or required attributes in a first resource.